Drop the inline enumeration of HTML ASCII whitespace code points and
shorten the explanation; keep the worked single- and multi-class
examples.

Identify the term and list the characters (tab, line feed, form feed,
carriage return, space) so readers know exactly what splits a value
into multiple class names.

Replace the paraphrased whitespace list with a blockquote of the
Infra Standard definition and add a `@see` link to the source.

Adopt the simpler note on the Tag Processor and mirror it on the HTML
Processor so both `add_class()` docblocks read the same.

Rewrite the lead sentence so it parses on one read, and restore the
explicit "not one class" cue on the multi-class example so the
docblock directly contradicts the natural misreading.

State directly that the value is added verbatim and may yield multiple
class names in the element's class list — "may" because trailing or
leading whitespace alone still produces a single class.

The body prose already names ASCII whitespace and explains the
multi-class effect, so the `@see` link and expanded `@param`
description are redundant. Restore the original `@param` text.

…e value.

The class name itself is HTML-escaped when written into the attribute;
only the whitespace passes through unchanged, which is what splits the
value into multiple class names.

…ace.

A class name cannot contain whitespace; the HTML class attribute is a
whitespace-separated token list. Pass-through whitespace in the
`$wanted_class` / `$class_name` argument can therefore never match a
real token, so reject it up front and return false. Document the new
behavior in both the Tag Processor and HTML Processor docblocks.

Behavior note: previously, `add_class('a b')` followed by
`remove_class('a b')` was an accidental no-op because the REMOVE
overwrote the ADD in the keyed updates map. With the short-circuit the
REMOVE is rejected and the ADD survives, so the element gets classes
"a" and "b" as the lone `add_class()` call would have produced.

The short-circuit is purely a performance refinement of an already
guaranteed result (no token can contain whitespace), not a meaningful
behavior change worth versioning. Keep the inline docblock note.

Add a `_doing_it_wrong()` call on the whitespace short-circuit in
`has_class()` and `remove_class()` so developers passing a value that
can never identify a class token see an actionable warning rather than
a silent false.

… docblocks.

The `_doing_it_wrong()` warning now communicates the constraint at the
point of misuse, so the docblock note is redundant.